pycram.orm.ormatic_interface

Attributes

executiondatadao_added_world_modifications_association
movetcpwaypointsmotiondao_waypoints_association
planmappingdao_nodes_association
planmappingdao_edges_association
shapecollectiondao_shapes_association
worldmappingdao_kinematic_structure_entities_association
worldmappingdao_connections_association
worldmappingdao_semantic_annotations_association
worldmappingdao_degrees_of_freedom_association
hasdoorsdao_doors_association
cupboarddao_doors_association
hasdrawersdao_drawers_association
cabinetdao_doors_association
cabinetdao_drawers_association
dresserdao_doors_association
dresserdao_drawers_association
wardrobedao_doors_association
wardrobedao_drawers_association
abstractrobotdao_manipulators_association
abstractrobotdao_sensors_association
abstractrobotdao_manipulator_chains_association
abstractrobotdao_sensor_chains_association
kinematicchaindao_sensors_association
worldmodelmodificationblockdao_modifications_association

Classes

Base	Base class used for declarative class definitions.
AccelerationVariableDAO	Base class used for declarative class definitions.
BoundingBoxDAO	Base class used for declarative class definitions.
CallbackDAO	Base class used for declarative class definitions.
CollisionCheckingConfigDAO	Base class used for declarative class definitions.
CollisionPairManagerDAO	Base class used for declarative class definitions.
ColorDAO	Base class used for declarative class definitions.
DesignatorDescriptionDAO	Base class used for declarative class definitions.
ActionDescriptionDAO	Base class used for declarative class definitions.
CarryActionDAO	Base class used for declarative class definitions.
CloseActionDAO	Base class used for declarative class definitions.
CuttingActionDAO	Base class used for declarative class definitions.
BaseMotionDAO	Base class used for declarative class definitions.
ClosingMotionDAO	Base class used for declarative class definitions.
DetectActionDAO	Base class used for declarative class definitions.
DetectingMotionDAO	Base class used for declarative class definitions.
EfficientTransportActionDAO	Base class used for declarative class definitions.
ExecutionDataDAO	Base class used for declarative class definitions.
FaceAtActionDAO	Base class used for declarative class definitions.
FieldOfViewDAO	Base class used for declarative class definitions.
GraspDescriptionDAO	Base class used for declarative class definitions.
GraspingActionDAO	Base class used for declarative class definitions.
HeaderDAO	Base class used for declarative class definitions.
HomogeneousTransformationMatrixMappingDAO	Base class used for declarative class definitions.
IsPerceivableDAO	Base class used for declarative class definitions.
JerkVariableDAO	Base class used for declarative class definitions.
LookAtActionDAO	Base class used for declarative class definitions.
LookingMotionDAO	Base class used for declarative class definitions.
MixingActionDAO	Base class used for declarative class definitions.
ModelChangeCallbackDAO	Base class used for declarative class definitions.
MoveAndPickUpActionDAO	Base class used for declarative class definitions.
MoveAndPlaceActionDAO	Base class used for declarative class definitions.
MoveGripperMotionDAO	Base class used for declarative class definitions.
MoveJointsMotionDAO	Base class used for declarative class definitions.
MoveMotionDAO	Base class used for declarative class definitions.
MoveTCPMotionDAO	Base class used for declarative class definitions.
MoveTCPWaypointsMotionDAO	Base class used for declarative class definitions.
MoveTorsoActionDAO	Base class used for declarative class definitions.
NavigateActionDAO	Base class used for declarative class definitions.
OpenActionDAO	Base class used for declarative class definitions.
OpeningMotionDAO	Base class used for declarative class definitions.
ParkArmsActionDAO	Base class used for declarative class definitions.
PickAndPlaceActionDAO	Base class used for declarative class definitions.
PickUpActionDAO	Base class used for declarative class definitions.
PlaceActionDAO	Base class used for declarative class definitions.
PlanMappingDAO	Base class used for declarative class definitions.
LanguagePlanDAO	Base class used for declarative class definitions.
CodePlanDAO	Base class used for declarative class definitions.
MonitorPlanDAO	Base class used for declarative class definitions.
ParallelPlanDAO	Base class used for declarative class definitions.
PlanEdgeDAO	Base class used for declarative class definitions.
PlanNodeMappingDAO	Base class used for declarative class definitions.
DesignatorNodeMappingDAO	Base class used for declarative class definitions.
ActionNodeMappingDAO	Base class used for declarative class definitions.
MotionNodeMappingDAO	Base class used for declarative class definitions.
LanguageNodeDAO	Base class used for declarative class definitions.
CodeNodeDAO	Base class used for declarative class definitions.
ParallelNodeDAO	Base class used for declarative class definitions.
Point3MappingDAO	Base class used for declarative class definitions.
PoseMappingDAO	Base class used for declarative class definitions.
PoseStampedDAO	Base class used for declarative class definitions.
GraspPoseDAO	Base class used for declarative class definitions.
PositionVariableDAO	Base class used for declarative class definitions.
PouringActionDAO	Base class used for declarative class definitions.
PreferredGraspAlignmentDAO	Base class used for declarative class definitions.
PrefixedNameDAO	Base class used for declarative class definitions.
PyCramPoseDAO	Base class used for declarative class definitions.
PyCRAMQuaternionMappingDAO	Base class used for declarative class definitions.
PyCramVector3DAO	Base class used for declarative class definitions.
QuaternionMappingDAO	Base class used for declarative class definitions.
ReachActionDAO	Base class used for declarative class definitions.
ReachMotionDAO	Base class used for declarative class definitions.
RepeatPlanDAO	Base class used for declarative class definitions.
ResolvedActionNodeMappingDAO	Base class used for declarative class definitions.
RotationMatrixMappingDAO	Base class used for declarative class definitions.
ScaleDAO	Base class used for declarative class definitions.
SearchActionDAO	Base class used for declarative class definitions.
SequentialNodeDAO	Base class used for declarative class definitions.
MonitorNodeDAO	Base class used for declarative class definitions.
RepeatNodeDAO	Base class used for declarative class definitions.
SequentialPlanDAO	Base class used for declarative class definitions.
SetGripperActionDAO	Base class used for declarative class definitions.
ShapeDAO	Base class used for declarative class definitions.
BoxDAO	Base class used for declarative class definitions.
CylinderDAO	Base class used for declarative class definitions.
MeshDAO	Base class used for declarative class definitions.
FileMeshDAO	Base class used for declarative class definitions.
ShapeCollectionDAO	Base class used for declarative class definitions.
BoundingBoxCollectionDAO	Base class used for declarative class definitions.
SpatialRelationDAO	Base class used for declarative class definitions.
InsideOfDAO	Base class used for declarative class definitions.
SphereDAO	Base class used for declarative class definitions.
StateChangeCallbackDAO	Base class used for declarative class definitions.
TransformDAO	Base class used for declarative class definitions.
TransformStampedDAO	Base class used for declarative class definitions.
TransportActionDAO	Base class used for declarative class definitions.
TriangleMeshDAO	Base class used for declarative class definitions.
TryAllNodeDAO	Base class used for declarative class definitions.
TryAllPLanDAO	Base class used for declarative class definitions.
TryInOrderNodeDAO	Base class used for declarative class definitions.
TryInOrderPlanDAO	Base class used for declarative class definitions.
Vector3MappingDAO	Base class used for declarative class definitions.
Vector3StampedDAO	Base class used for declarative class definitions.
VelocityVariableDAO	Base class used for declarative class definitions.
ViewDependentSpatialRelationDAO	Base class used for declarative class definitions.
AboveDAO	Base class used for declarative class definitions.
BehindDAO	Base class used for declarative class definitions.
BelowDAO	Base class used for declarative class definitions.
InFrontOfDAO	Base class used for declarative class definitions.
LeftOfDAO	Base class used for declarative class definitions.
RightOfDAO	Base class used for declarative class definitions.
WorldMappingDAO	Base class used for declarative class definitions.
WorldEntityDAO	Base class used for declarative class definitions.
ConnectionDAO	Base class used for declarative class definitions.
ActiveConnectionDAO	Base class used for declarative class definitions.
ActiveConnection1DOFDAO	Base class used for declarative class definitions.
PrismaticConnectionDAO	Base class used for declarative class definitions.
RevoluteConnectionDAO	Base class used for declarative class definitions.
OmniDriveDAO	Base class used for declarative class definitions.
Connection6DoFDAO	Base class used for declarative class definitions.
FixedConnectionDAO	Base class used for declarative class definitions.
SemanticAnnotationDAO	Base class used for declarative class definitions.
DoubleDoorDAO	Base class used for declarative class definitions.
DrawerDAO	Base class used for declarative class definitions.
FridgeDAO	Base class used for declarative class definitions.
FurnitureDAO	Base class used for declarative class definitions.
HasBodyDAO	Base class used for declarative class definitions.
BaseballDAO	Base class used for declarative class definitions.
BedDAO	Base class used for declarative class definitions.
BookDAO	Base class used for declarative class definitions.
BookFrontDAO	Base class used for declarative class definitions.
ChairDAO	Base class used for declarative class definitions.
ArmchairDAO	Base class used for declarative class definitions.
OfficeChairDAO	Base class used for declarative class definitions.
ClothDAO	Base class used for declarative class definitions.
ContainerDAO	Base class used for declarative class definitions.
BottleDAO	Base class used for declarative class definitions.
MustardBottleDAO	Base class used for declarative class definitions.
SoapBottleDAO	Base class used for declarative class definitions.
WineBottleDAO	Base class used for declarative class definitions.
GarbageBinDAO	Base class used for declarative class definitions.
ProcthorBoxDAO	Base class used for declarative class definitions.
SaltContainerDAO	Base class used for declarative class definitions.
CookingContainerDAO	Base class used for declarative class definitions.
KettleDAO	Base class used for declarative class definitions.
PanDAO	Base class used for declarative class definitions.
PotDAO	Base class used for declarative class definitions.
CuttleryDAO	Base class used for declarative class definitions.
ForkDAO	Base class used for declarative class definitions.
KnifeDAO	Base class used for declarative class definitions.
SpoonDAO	Base class used for declarative class definitions.
DecorDAO	Base class used for declarative class definitions.
WallDecorDAO	Base class used for declarative class definitions.
PosterDAO	Base class used for declarative class definitions.
DoorDAO	Base class used for declarative class definitions.
DrinkingContainerDAO	Base class used for declarative class definitions.
CupDAO	Base class used for declarative class definitions.
MugDAO	Base class used for declarative class definitions.
DroneDAO	Base class used for declarative class definitions.
FoodDAO	Base class used for declarative class definitions.
BreadDAO	Base class used for declarative class definitions.
CandyDAO	Base class used for declarative class definitions.
CerealDAO	Base class used for declarative class definitions.
CheezeItDAO	Base class used for declarative class definitions.
GelatinBoxDAO	Base class used for declarative class definitions.
MilkDAO	Base class used for declarative class definitions.
NoodlesDAO	Base class used for declarative class definitions.
PringlesDAO	Base class used for declarative class definitions.
ProduceDAO	Base class used for declarative class definitions.
AppleDAO	Base class used for declarative class definitions.
BananaDAO	Base class used for declarative class definitions.
LettuceDAO	Base class used for declarative class definitions.
OrangeDAO	Base class used for declarative class definitions.
PotatoDAO	Base class used for declarative class definitions.
TomatoDAO	Base class used for declarative class definitions.
TomatoSoupDAO	Base class used for declarative class definitions.
TunaCanDAO	Base class used for declarative class definitions.
HandleDAO	Base class used for declarative class definitions.
HouseplantDAO	Base class used for declarative class definitions.
LidDAO	Base class used for declarative class definitions.
PanLidDAO	Base class used for declarative class definitions.
PotLidDAO	Base class used for declarative class definitions.
LiquidCapDAO	Base class used for declarative class definitions.
PenDAO	Base class used for declarative class definitions.
PencilDAO	Base class used for declarative class definitions.
SaltPepperShakerDAO	Base class used for declarative class definitions.
ShelvingUnitDAO	Base class used for declarative class definitions.
SinkDAO	Base class used for declarative class definitions.
SofaDAO	Base class used for declarative class definitions.
SprayBottleDAO	Base class used for declarative class definitions.
StatueDAO	Base class used for declarative class definitions.
TableDAO	Base class used for declarative class definitions.
CoffeeTableDAO	Base class used for declarative class definitions.
DeskDAO	Base class used for declarative class definitions.
DiningTableDAO	Base class used for declarative class definitions.
SideTableDAO	Base class used for declarative class definitions.
VaseDAO	Base class used for declarative class definitions.
WallPanelDAO	Base class used for declarative class definitions.
HasDoorsDAO	Base class used for declarative class definitions.
CupboardDAO	Base class used for declarative class definitions.
HasDrawersDAO	Base class used for declarative class definitions.
CabinetDAO	Base class used for declarative class definitions.
DresserDAO	Base class used for declarative class definitions.
WardrobeDAO	Base class used for declarative class definitions.
HasRegionDAO	Base class used for declarative class definitions.
ApertureDAO	Base class used for declarative class definitions.
HasSupportingSurfaceDAO	Base class used for declarative class definitions.
BowlDAO	Base class used for declarative class definitions.
FloorDAO	Base class used for declarative class definitions.
PlateDAO	Base class used for declarative class definitions.
RoomDAO	Base class used for declarative class definitions.
RootedSemanticAnnotationDAO	Base class used for declarative class definitions.
AgentDAO	Base class used for declarative class definitions.
AbstractRobotDAO	Base class used for declarative class definitions.
HumanDAO	Base class used for declarative class definitions.
SemanticEnvironmentAnnotationDAO	Base class used for declarative class definitions.
SemanticRobotAnnotationDAO	Base class used for declarative class definitions.
KinematicChainDAO	Base class used for declarative class definitions.
ArmDAO	Base class used for declarative class definitions.
FingerDAO	Base class used for declarative class definitions.
NeckDAO	Base class used for declarative class definitions.
TorsoDAO	Base class used for declarative class definitions.
ManipulatorDAO	Base class used for declarative class definitions.
ParallelGripperDAO	Base class used for declarative class definitions.
SensorDAO	Base class used for declarative class definitions.
CameraDAO	Base class used for declarative class definitions.
WallDAO	Base class used for declarative class definitions.
WorldEntityWithIDDAO	Base class used for declarative class definitions.
ActuatorDAO	Base class used for declarative class definitions.
DegreeOfFreedomMappingDAO	Base class used for declarative class definitions.
KinematicStructureEntityDAO	Base class used for declarative class definitions.
BodyDAO	Base class used for declarative class definitions.
RegionDAO	Base class used for declarative class definitions.
WorldModelModificationDAO	Base class used for declarative class definitions.
AddActuatorModificationDAO	Base class used for declarative class definitions.
AddConnectionModificationDAO	Base class used for declarative class definitions.
AddDegreeOfFreedomModificationDAO	Base class used for declarative class definitions.
AddKinematicStructureEntityModificationDAO	Base class used for declarative class definitions.
AddSemanticAnnotationModificationDAO	Base class used for declarative class definitions.
RemoveActuatorModificationDAO	Base class used for declarative class definitions.
RemoveBodyModificationDAO	Base class used for declarative class definitions.
RemoveConnectionModificationDAO	Base class used for declarative class definitions.
RemoveDegreeOfFreedomModificationDAO	Base class used for declarative class definitions.
RemoveSemanticAnnotationModificationDAO	Base class used for declarative class definitions.
SetDofHasHardwareInterfaceDAO	Base class used for declarative class definitions.
WorldModelModificationBlockDAO	Base class used for declarative class definitions.
WorldStateMappingDAO	Base class used for declarative class definitions.

Module Contents

class pycram.orm.ormatic_interface.Base

Bases: sqlalchemy.orm.DeclarativeBase

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

type_mappings

pycram.orm.ormatic_interface.executiondatadao_added_world_modifications_association

pycram.orm.ormatic_interface.movetcpwaypointsmotiondao_waypoints_association

pycram.orm.ormatic_interface.planmappingdao_nodes_association

pycram.orm.ormatic_interface.planmappingdao_edges_association

pycram.orm.ormatic_interface.shapecollectiondao_shapes_association

pycram.orm.ormatic_interface.worldmappingdao_kinematic_structure_entities_association

pycram.orm.ormatic_interface.worldmappingdao_connections_association

pycram.orm.ormatic_interface.worldmappingdao_semantic_annotations_association

pycram.orm.ormatic_interface.worldmappingdao_degrees_of_freedom_association

pycram.orm.ormatic_interface.hasdoorsdao_doors_association

pycram.orm.ormatic_interface.cupboarddao_doors_association

pycram.orm.ormatic_interface.hasdrawersdao_drawers_association

pycram.orm.ormatic_interface.cabinetdao_doors_association

pycram.orm.ormatic_interface.cabinetdao_drawers_association

pycram.orm.ormatic_interface.dresserdao_doors_association

pycram.orm.ormatic_interface.dresserdao_drawers_association

pycram.orm.ormatic_interface.wardrobedao_doors_association

pycram.orm.ormatic_interface.wardrobedao_drawers_association

pycram.orm.ormatic_interface.abstractrobotdao_manipulators_association

pycram.orm.ormatic_interface.abstractrobotdao_sensors_association

pycram.orm.ormatic_interface.abstractrobotdao_manipulator_chains_association

pycram.orm.ormatic_interface.abstractrobotdao_sensor_chains_association

pycram.orm.ormatic_interface.kinematicchaindao_sensors_association

pycram.orm.ormatic_interface.worldmodelmodificationblockdao_modifications_association

class pycram.orm.ormatic_interface.AccelerationVariableDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.degree_of_freedom.AccelerationVariable]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'AccelerationVariableDAO'

database_id: sqlalchemy.orm.Mapped[int]

name: sqlalchemy.orm.Mapped[str]

dof_id: sqlalchemy.orm.Mapped[int]

dof: sqlalchemy.orm.Mapped[DegreeOfFreedomMappingDAO]

class pycram.orm.ormatic_interface.BoundingBoxDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.geometry.BoundingBox]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'BoundingBoxDAO'

database_id: sqlalchemy.orm.Mapped[int]

min_x: sqlalchemy.orm.Mapped[float]

min_y: sqlalchemy.orm.Mapped[float]

min_z: sqlalchemy.orm.Mapped[float]

max_x: sqlalchemy.orm.Mapped[float]

max_y: sqlalchemy.orm.Mapped[float]

max_z: sqlalchemy.orm.Mapped[float]

origin_id: sqlalchemy.orm.Mapped[int]

origin: sqlalchemy.orm.Mapped[HomogeneousTransformationMatrixMappingDAO]

class pycram.orm.ormatic_interface.CallbackDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.callbacks.callback.Callback]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'CallbackDAO'

database_id: sqlalchemy.orm.Mapped[int]

polymorphic_type: sqlalchemy.orm.Mapped[str]

world_id: sqlalchemy.orm.Mapped[int]

world: sqlalchemy.orm.Mapped[WorldMappingDAO]

__mapper_args__

class pycram.orm.ormatic_interface.CollisionCheckingConfigDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.world_entity.CollisionCheckingConfig]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'CollisionCheckingConfigDAO'

database_id: sqlalchemy.orm.Mapped[int]

buffer_zone_distance: sqlalchemy.orm.Mapped[float | None]

violated_distance: sqlalchemy.orm.Mapped[float]

disabled: sqlalchemy.orm.Mapped[bool | None]

max_avoided_bodies: sqlalchemy.orm.Mapped[int]

class pycram.orm.ormatic_interface.CollisionPairManagerDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world.CollisionPairManager]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'CollisionPairManagerDAO'

database_id: sqlalchemy.orm.Mapped[int]

world_id: sqlalchemy.orm.Mapped[int]

world: sqlalchemy.orm.Mapped[WorldMappingDAO]

class pycram.orm.ormatic_interface.ColorDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.geometry.Color]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'ColorDAO'

database_id: sqlalchemy.orm.Mapped[int]

R: sqlalchemy.orm.Mapped[float]

G: sqlalchemy.orm.Mapped[float]

B: sqlalchemy.orm.Mapped[float]

A: sqlalchemy.orm.Mapped[float]

class pycram.orm.ormatic_interface.DesignatorDescriptionDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[pycram.designator.DesignatorDescription]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'DesignatorDescriptionDAO'

database_id: sqlalchemy.orm.Mapped[int]

polymorphic_type: sqlalchemy.orm.Mapped[str]

plan_node_id: sqlalchemy.orm.Mapped[int]

plan_node: sqlalchemy.orm.Mapped[PlanNodeMappingDAO]

__mapper_args__

class pycram.orm.ormatic_interface.ActionDescriptionDAO

Bases: DesignatorDescriptionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.actions.base.ActionDescription]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'ActionDescriptionDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.CarryActionDAO

Bases: ActionDescriptionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.actions.core.robot_body.CarryAction]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'CarryActionDAO'

database_id: sqlalchemy.orm.Mapped[int]

arm: sqlalchemy.orm.Mapped[pycram.datastructures.enums.Arms]

align: sqlalchemy.orm.Mapped[bool | None]

tip_link: sqlalchemy.orm.Mapped[str | None]

root_link: sqlalchemy.orm.Mapped[str | None]

__mapper_args__

class pycram.orm.ormatic_interface.CloseActionDAO

Bases: ActionDescriptionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.actions.core.container.CloseAction]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'CloseActionDAO'

database_id: sqlalchemy.orm.Mapped[int]

arm: sqlalchemy.orm.Mapped[pycram.datastructures.enums.Arms]

grasping_prepose_distance: sqlalchemy.orm.Mapped[float]

object_designator_id: sqlalchemy.orm.Mapped[int]

object_designator: sqlalchemy.orm.Mapped[BodyDAO]

__mapper_args__

class pycram.orm.ormatic_interface.CuttingActionDAO

Bases: ActionDescriptionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.actions.composite.tool_based.CuttingAction]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'CuttingActionDAO'

database_id: sqlalchemy.orm.Mapped[int]

arm: sqlalchemy.orm.Mapped[pycram.datastructures.enums.Arms]

technique: sqlalchemy.orm.Mapped[str | None]

slice_thickness: sqlalchemy.orm.Mapped[float | None]

object__id: sqlalchemy.orm.Mapped[int]

tool_id: sqlalchemy.orm.Mapped[int]

object_: sqlalchemy.orm.Mapped[BodyDAO]

tool: sqlalchemy.orm.Mapped[SemanticAnnotationDAO]

__mapper_args__

class pycram.orm.ormatic_interface.BaseMotionDAO

Bases: DesignatorDescriptionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.motions.base.BaseMotion]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'BaseMotionDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.ClosingMotionDAO

Bases: BaseMotionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.motions.container.ClosingMotion]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'ClosingMotionDAO'

database_id: sqlalchemy.orm.Mapped[int]

arm: sqlalchemy.orm.Mapped[pycram.datastructures.enums.Arms]

object_part_id: sqlalchemy.orm.Mapped[int]

object_part: sqlalchemy.orm.Mapped[BodyDAO]

__mapper_args__

class pycram.orm.ormatic_interface.DetectActionDAO

Bases: ActionDescriptionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.actions.core.misc.DetectAction]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'DetectActionDAO'

database_id: sqlalchemy.orm.Mapped[int]

technique: sqlalchemy.orm.Mapped[pycram.datastructures.enums.DetectionTechnique]

object_sem_annotation: sqlalchemy.orm.Mapped[krrood.ormatic.custom_types.TypeType]

region_id: sqlalchemy.orm.Mapped[int | None]

region: sqlalchemy.orm.Mapped[RegionDAO]

__mapper_args__

class pycram.orm.ormatic_interface.DetectingMotionDAO

Bases: BaseMotionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.motions.misc.DetectingMotion]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'DetectingMotionDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.EfficientTransportActionDAO

Bases: ActionDescriptionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.actions.composite.transporting.EfficientTransportAction]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'EfficientTransportActionDAO'

database_id: sqlalchemy.orm.Mapped[int]

object_designator_id: sqlalchemy.orm.Mapped[int]

target_location_id: sqlalchemy.orm.Mapped[int]

object_designator: sqlalchemy.orm.Mapped[BodyDAO]

target_location: sqlalchemy.orm.Mapped[PoseStampedDAO]

__mapper_args__

class pycram.orm.ormatic_interface.ExecutionDataDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[pycram.datastructures.dataclasses.ExecutionData]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'ExecutionDataDAO'

database_id: sqlalchemy.orm.Mapped[int]

manipulated_body_name: sqlalchemy.orm.Mapped[str | None]

execution_start_world_state: sqlalchemy.orm.Mapped[pycram.orm.model.NumpyType]

execution_end_world_state: sqlalchemy.orm.Mapped[pycram.orm.model.NumpyType | None]

execution_start_pose_id: sqlalchemy.orm.Mapped[int]

execution_end_pose_id: sqlalchemy.orm.Mapped[int | None]

manipulated_body_pose_start_id: sqlalchemy.orm.Mapped[int | None]

manipulated_body_pose_end_id: sqlalchemy.orm.Mapped[int | None]

manipulated_body_id: sqlalchemy.orm.Mapped[int | None]

execution_start_pose: sqlalchemy.orm.Mapped[PoseStampedDAO]

execution_end_pose: sqlalchemy.orm.Mapped[PoseStampedDAO]

added_world_modifications: sqlalchemy.orm.Mapped[List[WorldModelModificationBlockDAO]]

manipulated_body_pose_start: sqlalchemy.orm.Mapped[PoseStampedDAO]

manipulated_body_pose_end: sqlalchemy.orm.Mapped[PoseStampedDAO]

manipulated_body: sqlalchemy.orm.Mapped[BodyDAO]

class pycram.orm.ormatic_interface.FaceAtActionDAO

Bases: ActionDescriptionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.actions.composite.facing.FaceAtAction]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'FaceAtActionDAO'

database_id: sqlalchemy.orm.Mapped[int]

keep_joint_states: sqlalchemy.orm.Mapped[bool]

pose_id: sqlalchemy.orm.Mapped[int]

pose: sqlalchemy.orm.Mapped[PoseStampedDAO]

__mapper_args__

class pycram.orm.ormatic_interface.FieldOfViewDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.robots.abstract_robot.FieldOfView]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'FieldOfViewDAO'

database_id: sqlalchemy.orm.Mapped[int]

vertical_angle: sqlalchemy.orm.Mapped[float]

horizontal_angle: sqlalchemy.orm.Mapped[float]

class pycram.orm.ormatic_interface.GraspDescriptionDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[pycram.datastructures.grasp.GraspDescription]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'GraspDescriptionDAO'

database_id: sqlalchemy.orm.Mapped[int]

approach_direction: sqlalchemy.orm.Mapped[pycram.datastructures.enums.ApproachDirection]

vertical_alignment: sqlalchemy.orm.Mapped[pycram.datastructures.enums.VerticalAlignment]

rotate_gripper: sqlalchemy.orm.Mapped[bool]

class pycram.orm.ormatic_interface.GraspingActionDAO

Bases: ActionDescriptionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.actions.core.pick_up.GraspingAction]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'GraspingActionDAO'

database_id: sqlalchemy.orm.Mapped[int]

arm: sqlalchemy.orm.Mapped[pycram.datastructures.enums.Arms]

prepose_distance: sqlalchemy.orm.Mapped[float]

object_designator_id: sqlalchemy.orm.Mapped[int]

object_designator: sqlalchemy.orm.Mapped[BodyDAO]

__mapper_args__

class pycram.orm.ormatic_interface.HeaderDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[pycram.datastructures.pose.Header]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'HeaderDAO'

database_id: sqlalchemy.orm.Mapped[int]

stamp: sqlalchemy.orm.Mapped[datetime.datetime]

sequence: sqlalchemy.orm.Mapped[int]

frame_id_id: sqlalchemy.orm.Mapped[int]

frame_id: sqlalchemy.orm.Mapped[BodyDAO]

class pycram.orm.ormatic_interface.HomogeneousTransformationMatrixMappingDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.orm.model.HomogeneousTransformationMatrixMapping]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'HomogeneousTransformationMatrixMappingDAO'

database_id: sqlalchemy.orm.Mapped[int]

position_id: sqlalchemy.orm.Mapped[int]

rotation_id: sqlalchemy.orm.Mapped[int]

reference_frame_id: sqlalchemy.orm.Mapped[int | None]

child_frame_id: sqlalchemy.orm.Mapped[int | None]

position: sqlalchemy.orm.Mapped[Point3MappingDAO]

rotation: sqlalchemy.orm.Mapped[QuaternionMappingDAO]

reference_frame: sqlalchemy.orm.Mapped[KinematicStructureEntityDAO]

child_frame: sqlalchemy.orm.Mapped[KinematicStructureEntityDAO]

class pycram.orm.ormatic_interface.IsPerceivableDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.IsPerceivable]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'IsPerceivableDAO'

database_id: sqlalchemy.orm.Mapped[int]

class_label: sqlalchemy.orm.Mapped[str | None]

polymorphic_type: sqlalchemy.orm.Mapped[str]

__mapper_args__

class pycram.orm.ormatic_interface.JerkVariableDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.degree_of_freedom.JerkVariable]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'JerkVariableDAO'

database_id: sqlalchemy.orm.Mapped[int]

name: sqlalchemy.orm.Mapped[str]

dof_id: sqlalchemy.orm.Mapped[int]

dof: sqlalchemy.orm.Mapped[DegreeOfFreedomMappingDAO]

class pycram.orm.ormatic_interface.LookAtActionDAO

Bases: ActionDescriptionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.actions.core.navigation.LookAtAction]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'LookAtActionDAO'

database_id: sqlalchemy.orm.Mapped[int]

target_id: sqlalchemy.orm.Mapped[int]

target: sqlalchemy.orm.Mapped[PoseStampedDAO]

__mapper_args__

class pycram.orm.ormatic_interface.LookingMotionDAO

Bases: BaseMotionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.motions.robot_body.LookingMotion]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'LookingMotionDAO'

database_id: sqlalchemy.orm.Mapped[int]

target_id: sqlalchemy.orm.Mapped[int]

target: sqlalchemy.orm.Mapped[PoseStampedDAO]

__mapper_args__

class pycram.orm.ormatic_interface.MixingActionDAO

Bases: ActionDescriptionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.actions.composite.tool_based.MixingAction]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'MixingActionDAO'

database_id: sqlalchemy.orm.Mapped[int]

arm: sqlalchemy.orm.Mapped[pycram.datastructures.enums.Arms]

technique: sqlalchemy.orm.Mapped[str | None]

object__id: sqlalchemy.orm.Mapped[int]

tool_id: sqlalchemy.orm.Mapped[int]

object_: sqlalchemy.orm.Mapped[BodyDAO]

tool: sqlalchemy.orm.Mapped[SemanticAnnotationDAO]

__mapper_args__

class pycram.orm.ormatic_interface.ModelChangeCallbackDAO

Bases: CallbackDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.callbacks.callback.ModelChangeCallback]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'ModelChangeCallbackDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.MoveAndPickUpActionDAO

Bases: ActionDescriptionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.actions.composite.transporting.MoveAndPickUpAction]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'MoveAndPickUpActionDAO'

database_id: sqlalchemy.orm.Mapped[int]

arm: sqlalchemy.orm.Mapped[pycram.datastructures.enums.Arms]

keep_joint_states: sqlalchemy.orm.Mapped[bool]

standing_position_id: sqlalchemy.orm.Mapped[int]

object_designator_id: sqlalchemy.orm.Mapped[int]

grasp_description_id: sqlalchemy.orm.Mapped[int]

standing_position: sqlalchemy.orm.Mapped[PoseStampedDAO]

object_designator: sqlalchemy.orm.Mapped[BodyDAO]

grasp_description: sqlalchemy.orm.Mapped[GraspDescriptionDAO]

__mapper_args__

class pycram.orm.ormatic_interface.MoveAndPlaceActionDAO

Bases: ActionDescriptionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.actions.composite.transporting.MoveAndPlaceAction]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'MoveAndPlaceActionDAO'

database_id: sqlalchemy.orm.Mapped[int]

arm: sqlalchemy.orm.Mapped[pycram.datastructures.enums.Arms]

keep_joint_states: sqlalchemy.orm.Mapped[bool]

standing_position_id: sqlalchemy.orm.Mapped[int]

object_designator_id: sqlalchemy.orm.Mapped[int]

target_location_id: sqlalchemy.orm.Mapped[int]

standing_position: sqlalchemy.orm.Mapped[PoseStampedDAO]

object_designator: sqlalchemy.orm.Mapped[BodyDAO]

target_location: sqlalchemy.orm.Mapped[PoseStampedDAO]

__mapper_args__

class pycram.orm.ormatic_interface.MoveGripperMotionDAO

Bases: BaseMotionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.motions.gripper.MoveGripperMotion]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'MoveGripperMotionDAO'

database_id: sqlalchemy.orm.Mapped[int]

motion: sqlalchemy.orm.Mapped[pycram.datastructures.enums.GripperState]

gripper: sqlalchemy.orm.Mapped[pycram.datastructures.enums.Arms]

allow_gripper_collision: sqlalchemy.orm.Mapped[bool | None]

__mapper_args__

class pycram.orm.ormatic_interface.MoveJointsMotionDAO

Bases: BaseMotionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.motions.robot_body.MoveJointsMotion]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'MoveJointsMotionDAO'

database_id: sqlalchemy.orm.Mapped[int]

align: sqlalchemy.orm.Mapped[bool | None]

tip_link: sqlalchemy.orm.Mapped[str | None]

root_link: sqlalchemy.orm.Mapped[str | None]

tip_normal_id: sqlalchemy.orm.Mapped[int | None]

root_normal_id: sqlalchemy.orm.Mapped[int | None]

tip_normal: sqlalchemy.orm.Mapped[Vector3StampedDAO]

root_normal: sqlalchemy.orm.Mapped[Vector3StampedDAO]

__mapper_args__

class pycram.orm.ormatic_interface.MoveMotionDAO

Bases: BaseMotionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.motions.navigation.MoveMotion]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'MoveMotionDAO'

database_id: sqlalchemy.orm.Mapped[int]

keep_joint_states: sqlalchemy.orm.Mapped[bool]

target_id: sqlalchemy.orm.Mapped[int]

target: sqlalchemy.orm.Mapped[PoseStampedDAO]

__mapper_args__

class pycram.orm.ormatic_interface.MoveTCPMotionDAO

Bases: BaseMotionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.motions.gripper.MoveTCPMotion]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'MoveTCPMotionDAO'

database_id: sqlalchemy.orm.Mapped[int]

arm: sqlalchemy.orm.Mapped[pycram.datastructures.enums.Arms]

allow_gripper_collision: sqlalchemy.orm.Mapped[bool | None]

target_id: sqlalchemy.orm.Mapped[int]

target: sqlalchemy.orm.Mapped[PoseStampedDAO]

__mapper_args__

class pycram.orm.ormatic_interface.MoveTCPWaypointsMotionDAO

Bases: BaseMotionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.motions.gripper.MoveTCPWaypointsMotion]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'MoveTCPWaypointsMotionDAO'

database_id: sqlalchemy.orm.Mapped[int]

arm: sqlalchemy.orm.Mapped[pycram.datastructures.enums.Arms]

allow_gripper_collision: sqlalchemy.orm.Mapped[bool | None]

movement_type: sqlalchemy.orm.Mapped[pycram.datastructures.enums.WaypointsMovementType]

waypoints: sqlalchemy.orm.Mapped[List[PoseStampedDAO]]

__mapper_args__

class pycram.orm.ormatic_interface.MoveTorsoActionDAO

Bases: ActionDescriptionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.actions.core.robot_body.MoveTorsoAction]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'MoveTorsoActionDAO'

database_id: sqlalchemy.orm.Mapped[int]

torso_state: sqlalchemy.orm.Mapped[pycram.datastructures.enums.TorsoState]

__mapper_args__

class pycram.orm.ormatic_interface.NavigateActionDAO

Bases: ActionDescriptionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.actions.core.navigation.NavigateAction]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'NavigateActionDAO'

database_id: sqlalchemy.orm.Mapped[int]

keep_joint_states: sqlalchemy.orm.Mapped[bool]

target_location_id: sqlalchemy.orm.Mapped[int]

target_location: sqlalchemy.orm.Mapped[PoseStampedDAO]

__mapper_args__

class pycram.orm.ormatic_interface.OpenActionDAO

Bases: ActionDescriptionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.actions.core.container.OpenAction]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'OpenActionDAO'

database_id: sqlalchemy.orm.Mapped[int]

arm: sqlalchemy.orm.Mapped[pycram.datastructures.enums.Arms]

grasping_prepose_distance: sqlalchemy.orm.Mapped[float]

object_designator_id: sqlalchemy.orm.Mapped[int]

object_designator: sqlalchemy.orm.Mapped[BodyDAO]

__mapper_args__

class pycram.orm.ormatic_interface.OpeningMotionDAO

Bases: BaseMotionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.motions.container.OpeningMotion]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'OpeningMotionDAO'

database_id: sqlalchemy.orm.Mapped[int]

arm: sqlalchemy.orm.Mapped[pycram.datastructures.enums.Arms]

object_part_id: sqlalchemy.orm.Mapped[int]

object_part: sqlalchemy.orm.Mapped[BodyDAO]

__mapper_args__

class pycram.orm.ormatic_interface.ParkArmsActionDAO

Bases: ActionDescriptionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.actions.core.robot_body.ParkArmsAction]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'ParkArmsActionDAO'

database_id: sqlalchemy.orm.Mapped[int]

arm: sqlalchemy.orm.Mapped[pycram.datastructures.enums.Arms]

__mapper_args__

class pycram.orm.ormatic_interface.PickAndPlaceActionDAO

Bases: ActionDescriptionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.actions.composite.transporting.PickAndPlaceAction]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'PickAndPlaceActionDAO'

database_id: sqlalchemy.orm.Mapped[int]

arm: sqlalchemy.orm.Mapped[pycram.datastructures.enums.Arms]

object_designator_id: sqlalchemy.orm.Mapped[int]

target_location_id: sqlalchemy.orm.Mapped[int]

grasp_description_id: sqlalchemy.orm.Mapped[int]

object_designator: sqlalchemy.orm.Mapped[BodyDAO]

target_location: sqlalchemy.orm.Mapped[PoseStampedDAO]

grasp_description: sqlalchemy.orm.Mapped[GraspDescriptionDAO]

__mapper_args__

class pycram.orm.ormatic_interface.PickUpActionDAO

Bases: ActionDescriptionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.actions.core.pick_up.PickUpAction]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'PickUpActionDAO'

database_id: sqlalchemy.orm.Mapped[int]

arm: sqlalchemy.orm.Mapped[pycram.datastructures.enums.Arms]

object_designator_id: sqlalchemy.orm.Mapped[int]

grasp_description_id: sqlalchemy.orm.Mapped[int]

object_designator: sqlalchemy.orm.Mapped[BodyDAO]

grasp_description: sqlalchemy.orm.Mapped[GraspDescriptionDAO]

__mapper_args__

class pycram.orm.ormatic_interface.PlaceActionDAO

Bases: ActionDescriptionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.actions.core.placing.PlaceAction]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'PlaceActionDAO'

database_id: sqlalchemy.orm.Mapped[int]

arm: sqlalchemy.orm.Mapped[pycram.datastructures.enums.Arms]

object_designator_id: sqlalchemy.orm.Mapped[int]

target_location_id: sqlalchemy.orm.Mapped[int]

object_designator: sqlalchemy.orm.Mapped[BodyDAO]

target_location: sqlalchemy.orm.Mapped[PoseStampedDAO]

__mapper_args__

class pycram.orm.ormatic_interface.PlanMappingDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[pycram.orm.model.PlanMapping]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'PlanMappingDAO'

database_id: sqlalchemy.orm.Mapped[int]

polymorphic_type: sqlalchemy.orm.Mapped[str]

nodes: sqlalchemy.orm.Mapped[List[PlanNodeMappingDAO]]

edges: sqlalchemy.orm.Mapped[List[PlanEdgeDAO]]

__mapper_args__

class pycram.orm.ormatic_interface.LanguagePlanDAO

Bases: PlanMappingDAO, krrood.ormatic.dao.DataAccessObject[pycram.language.LanguagePlan]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'LanguagePlanDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.CodePlanDAO

Bases: LanguagePlanDAO, krrood.ormatic.dao.DataAccessObject[pycram.language.CodePlan]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'CodePlanDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.MonitorPlanDAO

Bases: LanguagePlanDAO, krrood.ormatic.dao.DataAccessObject[pycram.language.MonitorPlan]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'MonitorPlanDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.ParallelPlanDAO

Bases: LanguagePlanDAO, krrood.ormatic.dao.DataAccessObject[pycram.language.ParallelPlan]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'ParallelPlanDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.PlanEdgeDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[pycram.orm.model.PlanEdge]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'PlanEdgeDAO'

database_id: sqlalchemy.orm.Mapped[int]

parent_id: sqlalchemy.orm.Mapped[int]

child_id: sqlalchemy.orm.Mapped[int]

parent: sqlalchemy.orm.Mapped[PlanNodeMappingDAO]

child: sqlalchemy.orm.Mapped[PlanNodeMappingDAO]

class pycram.orm.ormatic_interface.PlanNodeMappingDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[pycram.orm.model.PlanNodeMapping]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'PlanNodeMappingDAO'

database_id: sqlalchemy.orm.Mapped[int]

status: sqlalchemy.orm.Mapped[pycram.datastructures.enums.TaskStatus]

start_time: sqlalchemy.orm.Mapped[datetime.datetime | None]

end_time: sqlalchemy.orm.Mapped[datetime.datetime | None]

polymorphic_type: sqlalchemy.orm.Mapped[str]

__mapper_args__

class pycram.orm.ormatic_interface.DesignatorNodeMappingDAO

Bases: PlanNodeMappingDAO, krrood.ormatic.dao.DataAccessObject[pycram.orm.model.DesignatorNodeMapping]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'DesignatorNodeMappingDAO'

database_id: sqlalchemy.orm.Mapped[int]

designator_type: sqlalchemy.orm.Mapped[krrood.ormatic.custom_types.TypeType]

designator_ref_id: sqlalchemy.orm.Mapped[int]

designator_ref: sqlalchemy.orm.Mapped[DesignatorDescriptionDAO]

__mapper_args__

class pycram.orm.ormatic_interface.ActionNodeMappingDAO

Bases: DesignatorNodeMappingDAO, krrood.ormatic.dao.DataAccessObject[pycram.orm.model.ActionNodeMapping]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'ActionNodeMappingDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.MotionNodeMappingDAO

Bases: DesignatorNodeMappingDAO, krrood.ormatic.dao.DataAccessObject[pycram.orm.model.MotionNodeMapping]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'MotionNodeMappingDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.LanguageNodeDAO

Bases: PlanNodeMappingDAO, krrood.ormatic.dao.DataAccessObject[pycram.language.LanguageNode]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'LanguageNodeDAO'

database_id: sqlalchemy.orm.Mapped[int]

designator_type: sqlalchemy.orm.Mapped[krrood.ormatic.custom_types.TypeType]

__mapper_args__

class pycram.orm.ormatic_interface.CodeNodeDAO

Bases: LanguageNodeDAO, krrood.ormatic.dao.DataAccessObject[pycram.language.CodeNode]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'CodeNodeDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.ParallelNodeDAO

Bases: LanguageNodeDAO, krrood.ormatic.dao.DataAccessObject[pycram.language.ParallelNode]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'ParallelNodeDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.Point3MappingDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.orm.model.Point3Mapping]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'Point3MappingDAO'

database_id: sqlalchemy.orm.Mapped[int]

x: sqlalchemy.orm.Mapped[float]

y: sqlalchemy.orm.Mapped[float]

z: sqlalchemy.orm.Mapped[float]

reference_frame_id: sqlalchemy.orm.Mapped[int | None]

reference_frame: sqlalchemy.orm.Mapped[KinematicStructureEntityDAO]

class pycram.orm.ormatic_interface.PoseMappingDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.orm.model.PoseMapping]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'PoseMappingDAO'

database_id: sqlalchemy.orm.Mapped[int]

position_id: sqlalchemy.orm.Mapped[int]

rotation_id: sqlalchemy.orm.Mapped[int]

reference_frame_id: sqlalchemy.orm.Mapped[int | None]

position: sqlalchemy.orm.Mapped[Point3MappingDAO]

rotation: sqlalchemy.orm.Mapped[QuaternionMappingDAO]

reference_frame: sqlalchemy.orm.Mapped[KinematicStructureEntityDAO]

class pycram.orm.ormatic_interface.PoseStampedDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[pycram.datastructures.pose.PoseStamped]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'PoseStampedDAO'

database_id: sqlalchemy.orm.Mapped[int]

polymorphic_type: sqlalchemy.orm.Mapped[str]

pose_id: sqlalchemy.orm.Mapped[int]

header_id: sqlalchemy.orm.Mapped[int]

pose: sqlalchemy.orm.Mapped[PyCramPoseDAO]

header: sqlalchemy.orm.Mapped[HeaderDAO]

__mapper_args__

class pycram.orm.ormatic_interface.GraspPoseDAO

Bases: PoseStampedDAO, krrood.ormatic.dao.DataAccessObject[pycram.datastructures.pose.GraspPose]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'GraspPoseDAO'

database_id: sqlalchemy.orm.Mapped[int]

arm: sqlalchemy.orm.Mapped[pycram.datastructures.enums.Arms]

grasp_description_id: sqlalchemy.orm.Mapped[int]

grasp_description: sqlalchemy.orm.Mapped[GraspDescriptionDAO]

__mapper_args__

class pycram.orm.ormatic_interface.PositionVariableDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.degree_of_freedom.PositionVariable]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'PositionVariableDAO'

database_id: sqlalchemy.orm.Mapped[int]

name: sqlalchemy.orm.Mapped[str]

dof_id: sqlalchemy.orm.Mapped[int]

dof: sqlalchemy.orm.Mapped[DegreeOfFreedomMappingDAO]

class pycram.orm.ormatic_interface.PouringActionDAO

Bases: ActionDescriptionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.actions.composite.tool_based.PouringAction]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'PouringActionDAO'

database_id: sqlalchemy.orm.Mapped[int]

arm: sqlalchemy.orm.Mapped[pycram.datastructures.enums.Arms]

technique: sqlalchemy.orm.Mapped[str | None]

angle: sqlalchemy.orm.Mapped[float | None]

object__id: sqlalchemy.orm.Mapped[int]

tool_id: sqlalchemy.orm.Mapped[int]

object_: sqlalchemy.orm.Mapped[BodyDAO]

tool: sqlalchemy.orm.Mapped[SemanticAnnotationDAO]

__mapper_args__

class pycram.orm.ormatic_interface.PreferredGraspAlignmentDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[pycram.datastructures.grasp.PreferredGraspAlignment]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'PreferredGraspAlignmentDAO'

database_id: sqlalchemy.orm.Mapped[int]

with_vertical_alignment: sqlalchemy.orm.Mapped[bool]

with_rotated_gripper: sqlalchemy.orm.Mapped[bool]

class pycram.orm.ormatic_interface.PrefixedNameDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.datastructures.prefixed_name.PrefixedName]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'PrefixedNameDAO'

database_id: sqlalchemy.orm.Mapped[int]

name: sqlalchemy.orm.Mapped[str]

prefix: sqlalchemy.orm.Mapped[str | None]

class pycram.orm.ormatic_interface.PyCramPoseDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[pycram.datastructures.pose.PyCramPose]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'PyCramPoseDAO'

database_id: sqlalchemy.orm.Mapped[int]

polymorphic_type: sqlalchemy.orm.Mapped[str]

position_id: sqlalchemy.orm.Mapped[int]

orientation_id: sqlalchemy.orm.Mapped[int]

position: sqlalchemy.orm.Mapped[PyCramVector3DAO]

orientation: sqlalchemy.orm.Mapped[PyCRAMQuaternionMappingDAO]

__mapper_args__

class pycram.orm.ormatic_interface.PyCRAMQuaternionMappingDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[pycram.orm.model.PyCRAMQuaternionMapping]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'PyCRAMQuaternionMappingDAO'

database_id: sqlalchemy.orm.Mapped[int]

x: sqlalchemy.orm.Mapped[float]

y: sqlalchemy.orm.Mapped[float]

z: sqlalchemy.orm.Mapped[float]

w: sqlalchemy.orm.Mapped[float]

class pycram.orm.ormatic_interface.PyCramVector3DAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[pycram.datastructures.pose.PyCramVector3]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'PyCramVector3DAO'

database_id: sqlalchemy.orm.Mapped[int]

x: sqlalchemy.orm.Mapped[float]

y: sqlalchemy.orm.Mapped[float]

z: sqlalchemy.orm.Mapped[float]

polymorphic_type: sqlalchemy.orm.Mapped[str]

__mapper_args__

class pycram.orm.ormatic_interface.QuaternionMappingDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.orm.model.QuaternionMapping]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'QuaternionMappingDAO'

database_id: sqlalchemy.orm.Mapped[int]

x: sqlalchemy.orm.Mapped[float]

y: sqlalchemy.orm.Mapped[float]

z: sqlalchemy.orm.Mapped[float]

w: sqlalchemy.orm.Mapped[float]

reference_frame_id: sqlalchemy.orm.Mapped[int | None]

reference_frame: sqlalchemy.orm.Mapped[KinematicStructureEntityDAO]

class pycram.orm.ormatic_interface.ReachActionDAO

Bases: ActionDescriptionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.actions.core.pick_up.ReachAction]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'ReachActionDAO'

database_id: sqlalchemy.orm.Mapped[int]

arm: sqlalchemy.orm.Mapped[pycram.datastructures.enums.Arms]

target_pose_id: sqlalchemy.orm.Mapped[int]

grasp_description_id: sqlalchemy.orm.Mapped[int]

object_designator_id: sqlalchemy.orm.Mapped[int]

target_pose: sqlalchemy.orm.Mapped[PoseStampedDAO]

grasp_description: sqlalchemy.orm.Mapped[GraspDescriptionDAO]

object_designator: sqlalchemy.orm.Mapped[BodyDAO]

__mapper_args__

class pycram.orm.ormatic_interface.ReachMotionDAO

Bases: BaseMotionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.motions.gripper.ReachMotion]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'ReachMotionDAO'

database_id: sqlalchemy.orm.Mapped[int]

arm: sqlalchemy.orm.Mapped[pycram.datastructures.enums.Arms]

movement_type: sqlalchemy.orm.Mapped[pycram.datastructures.enums.MovementType]

reverse_pose_sequence: sqlalchemy.orm.Mapped[bool]

object_designator_id: sqlalchemy.orm.Mapped[int]

grasp_description_id: sqlalchemy.orm.Mapped[int]

object_designator: sqlalchemy.orm.Mapped[BodyDAO]

grasp_description: sqlalchemy.orm.Mapped[GraspDescriptionDAO]

__mapper_args__

class pycram.orm.ormatic_interface.RepeatPlanDAO

Bases: LanguagePlanDAO, krrood.ormatic.dao.DataAccessObject[pycram.language.RepeatPlan]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'RepeatPlanDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.ResolvedActionNodeMappingDAO

Bases: DesignatorNodeMappingDAO, krrood.ormatic.dao.DataAccessObject[pycram.orm.model.ResolvedActionNodeMapping]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'ResolvedActionNodeMappingDAO'

database_id: sqlalchemy.orm.Mapped[int]

execution_data_id: sqlalchemy.orm.Mapped[int]

execution_data: sqlalchemy.orm.Mapped[ExecutionDataDAO]

__mapper_args__

class pycram.orm.ormatic_interface.RotationMatrixMappingDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.orm.model.RotationMatrixMapping]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'RotationMatrixMappingDAO'

database_id: sqlalchemy.orm.Mapped[int]

rotation_id: sqlalchemy.orm.Mapped[int]

reference_frame_id: sqlalchemy.orm.Mapped[int | None]

rotation: sqlalchemy.orm.Mapped[QuaternionMappingDAO]

reference_frame: sqlalchemy.orm.Mapped[KinematicStructureEntityDAO]

class pycram.orm.ormatic_interface.ScaleDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.geometry.Scale]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'ScaleDAO'

database_id: sqlalchemy.orm.Mapped[int]

x: sqlalchemy.orm.Mapped[float]

y: sqlalchemy.orm.Mapped[float]

z: sqlalchemy.orm.Mapped[float]

class pycram.orm.ormatic_interface.SearchActionDAO

Bases: ActionDescriptionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.actions.composite.searching.SearchAction]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'SearchActionDAO'

database_id: sqlalchemy.orm.Mapped[int]

object_sem_annotation: sqlalchemy.orm.Mapped[krrood.ormatic.custom_types.TypeType]

target_location_id: sqlalchemy.orm.Mapped[int]

target_location: sqlalchemy.orm.Mapped[PoseStampedDAO]

__mapper_args__

class pycram.orm.ormatic_interface.SequentialNodeDAO

Bases: LanguageNodeDAO, krrood.ormatic.dao.DataAccessObject[pycram.language.SequentialNode]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'SequentialNodeDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.MonitorNodeDAO

Bases: SequentialNodeDAO, krrood.ormatic.dao.DataAccessObject[pycram.language.MonitorNode]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'MonitorNodeDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.RepeatNodeDAO

Bases: SequentialNodeDAO, krrood.ormatic.dao.DataAccessObject[pycram.language.RepeatNode]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'RepeatNodeDAO'

database_id: sqlalchemy.orm.Mapped[int]

repeat: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.SequentialPlanDAO

Bases: LanguagePlanDAO, krrood.ormatic.dao.DataAccessObject[pycram.language.SequentialPlan]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'SequentialPlanDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.SetGripperActionDAO

Bases: ActionDescriptionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.actions.core.robot_body.SetGripperAction]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'SetGripperActionDAO'

database_id: sqlalchemy.orm.Mapped[int]

gripper: sqlalchemy.orm.Mapped[pycram.datastructures.enums.Arms]

motion: sqlalchemy.orm.Mapped[pycram.datastructures.enums.GripperState]

__mapper_args__

class pycram.orm.ormatic_interface.ShapeDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.geometry.Shape]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'ShapeDAO'

database_id: sqlalchemy.orm.Mapped[int]

polymorphic_type: sqlalchemy.orm.Mapped[str]

origin_id: sqlalchemy.orm.Mapped[int]

color_id: sqlalchemy.orm.Mapped[int]

origin: sqlalchemy.orm.Mapped[HomogeneousTransformationMatrixMappingDAO]

color: sqlalchemy.orm.Mapped[ColorDAO]

__mapper_args__

class pycram.orm.ormatic_interface.BoxDAO

Bases: ShapeDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.geometry.Box]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'BoxDAO'

database_id: sqlalchemy.orm.Mapped[int]

scale_id: sqlalchemy.orm.Mapped[int]

scale: sqlalchemy.orm.Mapped[ScaleDAO]

__mapper_args__

class pycram.orm.ormatic_interface.CylinderDAO

Bases: ShapeDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.geometry.Cylinder]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'CylinderDAO'

database_id: sqlalchemy.orm.Mapped[int]

width: sqlalchemy.orm.Mapped[float]

height: sqlalchemy.orm.Mapped[float]

__mapper_args__

class pycram.orm.ormatic_interface.MeshDAO

Bases: ShapeDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.geometry.Mesh]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'MeshDAO'

database_id: sqlalchemy.orm.Mapped[int]

scale_id: sqlalchemy.orm.Mapped[int]

scale: sqlalchemy.orm.Mapped[ScaleDAO]

__mapper_args__

class pycram.orm.ormatic_interface.FileMeshDAO

Bases: MeshDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.geometry.FileMesh]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'FileMeshDAO'

database_id: sqlalchemy.orm.Mapped[int]

filename: sqlalchemy.orm.Mapped[str]

__mapper_args__

class pycram.orm.ormatic_interface.ShapeCollectionDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.shape_collection.ShapeCollection]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'ShapeCollectionDAO'

database_id: sqlalchemy.orm.Mapped[int]

polymorphic_type: sqlalchemy.orm.Mapped[str]

reference_frame_id: sqlalchemy.orm.Mapped[int | None]

shapes: sqlalchemy.orm.Mapped[List[ShapeDAO]]

reference_frame: sqlalchemy.orm.Mapped[KinematicStructureEntityDAO]

__mapper_args__

class pycram.orm.ormatic_interface.BoundingBoxCollectionDAO

Bases: ShapeCollectionDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.shape_collection.BoundingBoxCollection]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'BoundingBoxCollectionDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.SpatialRelationDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.reasoning.predicates.SpatialRelation]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'SpatialRelationDAO'

database_id: sqlalchemy.orm.Mapped[int]

polymorphic_type: sqlalchemy.orm.Mapped[str]

body_id: sqlalchemy.orm.Mapped[int]

other_id: sqlalchemy.orm.Mapped[int]

body: sqlalchemy.orm.Mapped[KinematicStructureEntityDAO]

other: sqlalchemy.orm.Mapped[KinematicStructureEntityDAO]

__mapper_args__

class pycram.orm.ormatic_interface.InsideOfDAO

Bases: SpatialRelationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.reasoning.predicates.InsideOf]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'InsideOfDAO'

database_id: sqlalchemy.orm.Mapped[int]

containment_ratio: sqlalchemy.orm.Mapped[float]

__mapper_args__

class pycram.orm.ormatic_interface.SphereDAO

Bases: ShapeDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.geometry.Sphere]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'SphereDAO'

database_id: sqlalchemy.orm.Mapped[int]

radius: sqlalchemy.orm.Mapped[float]

__mapper_args__

class pycram.orm.ormatic_interface.StateChangeCallbackDAO

Bases: CallbackDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.callbacks.callback.StateChangeCallback]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'StateChangeCallbackDAO'

database_id: sqlalchemy.orm.Mapped[int]

previous_world_state_data: sqlalchemy.orm.Mapped[pycram.orm.model.NumpyType]

__mapper_args__

class pycram.orm.ormatic_interface.TransformDAO

Bases: PyCramPoseDAO, krrood.ormatic.dao.DataAccessObject[pycram.datastructures.pose.Transform]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'TransformDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.TransformStampedDAO

Bases: PoseStampedDAO, krrood.ormatic.dao.DataAccessObject[pycram.datastructures.pose.TransformStamped]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'TransformStampedDAO'

database_id: sqlalchemy.orm.Mapped[int]

child_frame_id_id: sqlalchemy.orm.Mapped[int]

child_frame_id: sqlalchemy.orm.Mapped[BodyDAO]

__mapper_args__

class pycram.orm.ormatic_interface.TransportActionDAO

Bases: ActionDescriptionDAO, krrood.ormatic.dao.DataAccessObject[pycram.robot_plans.actions.composite.transporting.TransportAction]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'TransportActionDAO'

database_id: sqlalchemy.orm.Mapped[int]

place_rotation_agnostic: sqlalchemy.orm.Mapped[bool | None]

object_designator_id: sqlalchemy.orm.Mapped[int]

target_location_id: sqlalchemy.orm.Mapped[int]

object_designator: sqlalchemy.orm.Mapped[BodyDAO]

target_location: sqlalchemy.orm.Mapped[PoseStampedDAO]

__mapper_args__

class pycram.orm.ormatic_interface.TriangleMeshDAO

Bases: MeshDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.geometry.TriangleMesh]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'TriangleMeshDAO'

database_id: sqlalchemy.orm.Mapped[int]

mesh: sqlalchemy.orm.Mapped[semantic_digital_twin.orm.model.TrimeshType | None]

__mapper_args__

class pycram.orm.ormatic_interface.TryAllNodeDAO

Bases: ParallelNodeDAO, krrood.ormatic.dao.DataAccessObject[pycram.language.TryAllNode]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'TryAllNodeDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.TryAllPLanDAO

Bases: ParallelPlanDAO, krrood.ormatic.dao.DataAccessObject[pycram.language.TryAllPLan]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'TryAllPLanDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.TryInOrderNodeDAO

Bases: SequentialNodeDAO, krrood.ormatic.dao.DataAccessObject[pycram.language.TryInOrderNode]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'TryInOrderNodeDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.TryInOrderPlanDAO

Bases: LanguagePlanDAO, krrood.ormatic.dao.DataAccessObject[pycram.language.TryInOrderPlan]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'TryInOrderPlanDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.Vector3MappingDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.orm.model.Vector3Mapping]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'Vector3MappingDAO'

database_id: sqlalchemy.orm.Mapped[int]

x: sqlalchemy.orm.Mapped[float]

y: sqlalchemy.orm.Mapped[float]

z: sqlalchemy.orm.Mapped[float]

reference_frame_id: sqlalchemy.orm.Mapped[int | None]

reference_frame: sqlalchemy.orm.Mapped[KinematicStructureEntityDAO]

class pycram.orm.ormatic_interface.Vector3StampedDAO

Bases: PyCramVector3DAO, krrood.ormatic.dao.DataAccessObject[pycram.datastructures.pose.Vector3Stamped]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'Vector3StampedDAO'

database_id: sqlalchemy.orm.Mapped[int]

header_id: sqlalchemy.orm.Mapped[int]

header: sqlalchemy.orm.Mapped[HeaderDAO]

__mapper_args__

class pycram.orm.ormatic_interface.VelocityVariableDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.degree_of_freedom.VelocityVariable]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'VelocityVariableDAO'

database_id: sqlalchemy.orm.Mapped[int]

name: sqlalchemy.orm.Mapped[str]

dof_id: sqlalchemy.orm.Mapped[int]

dof: sqlalchemy.orm.Mapped[DegreeOfFreedomMappingDAO]

class pycram.orm.ormatic_interface.ViewDependentSpatialRelationDAO

Bases: SpatialRelationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.reasoning.predicates.ViewDependentSpatialRelation]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'ViewDependentSpatialRelationDAO'

database_id: sqlalchemy.orm.Mapped[int]

eps: sqlalchemy.orm.Mapped[float]

spatial_relation_result: sqlalchemy.orm.Mapped[bool]

point_of_semantic_annotation_id: sqlalchemy.orm.Mapped[int]

point_of_semantic_annotation: sqlalchemy.orm.Mapped[HomogeneousTransformationMatrixMappingDAO]

__mapper_args__

class pycram.orm.ormatic_interface.AboveDAO

Bases: ViewDependentSpatialRelationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.reasoning.predicates.Above]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'AboveDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.BehindDAO

Bases: ViewDependentSpatialRelationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.reasoning.predicates.Behind]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'BehindDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.BelowDAO

Bases: ViewDependentSpatialRelationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.reasoning.predicates.Below]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'BelowDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.InFrontOfDAO

Bases: ViewDependentSpatialRelationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.reasoning.predicates.InFrontOf]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'InFrontOfDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.LeftOfDAO

Bases: ViewDependentSpatialRelationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.reasoning.predicates.LeftOf]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'LeftOfDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.RightOfDAO

Bases: ViewDependentSpatialRelationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.reasoning.predicates.RightOf]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'RightOfDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.WorldMappingDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.orm.model.WorldMapping]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'WorldMappingDAO'

database_id: sqlalchemy.orm.Mapped[int]

name: sqlalchemy.orm.Mapped[str | None]

state_id: sqlalchemy.orm.Mapped[int]

kinematic_structure_entities: sqlalchemy.orm.Mapped[List[KinematicStructureEntityDAO]]

connections: sqlalchemy.orm.Mapped[List[ConnectionDAO]]

semantic_annotations: sqlalchemy.orm.Mapped[List[SemanticAnnotationDAO]]

degrees_of_freedom: sqlalchemy.orm.Mapped[List[DegreeOfFreedomMappingDAO]]

state: sqlalchemy.orm.Mapped[WorldStateMappingDAO]

class pycram.orm.ormatic_interface.WorldEntityDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.world_entity.WorldEntity]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'WorldEntityDAO'

database_id: sqlalchemy.orm.Mapped[int]

polymorphic_type: sqlalchemy.orm.Mapped[str]

name_id: sqlalchemy.orm.Mapped[int]

name: sqlalchemy.orm.Mapped[PrefixedNameDAO]

__mapper_args__

class pycram.orm.ormatic_interface.ConnectionDAO

Bases: WorldEntityDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.world_entity.Connection]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'ConnectionDAO'

database_id: sqlalchemy.orm.Mapped[int]

parent_id: sqlalchemy.orm.Mapped[int]

child_id: sqlalchemy.orm.Mapped[int]

parent_T_connection_expression_id: sqlalchemy.orm.Mapped[int]

connection_T_child_expression_id: sqlalchemy.orm.Mapped[int]

parent: sqlalchemy.orm.Mapped[KinematicStructureEntityDAO]

child: sqlalchemy.orm.Mapped[KinematicStructureEntityDAO]

parent_T_connection_expression: sqlalchemy.orm.Mapped[HomogeneousTransformationMatrixMappingDAO]

connection_T_child_expression: sqlalchemy.orm.Mapped[HomogeneousTransformationMatrixMappingDAO]

__mapper_args__

class pycram.orm.ormatic_interface.ActiveConnectionDAO

Bases: ConnectionDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.connections.ActiveConnection]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'ActiveConnectionDAO'

database_id: sqlalchemy.orm.Mapped[int]

frozen_for_collision_avoidance: sqlalchemy.orm.Mapped[bool]

__mapper_args__

class pycram.orm.ormatic_interface.ActiveConnection1DOFDAO

Bases: ActiveConnectionDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.connections.ActiveConnection1DOF]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'ActiveConnection1DOFDAO'

database_id: sqlalchemy.orm.Mapped[int]

multiplier: sqlalchemy.orm.Mapped[float]

offset: sqlalchemy.orm.Mapped[float]

dof_id: sqlalchemy.orm.Mapped[sqlalchemy.sql.sqltypes.UUID]

axis_id: sqlalchemy.orm.Mapped[int]

axis: sqlalchemy.orm.Mapped[Vector3MappingDAO]

__mapper_args__

class pycram.orm.ormatic_interface.PrismaticConnectionDAO

Bases: ActiveConnection1DOFDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.connections.PrismaticConnection]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'PrismaticConnectionDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.RevoluteConnectionDAO

Bases: ActiveConnection1DOFDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.connections.RevoluteConnection]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'RevoluteConnectionDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.OmniDriveDAO

Bases: ActiveConnectionDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.connections.OmniDrive]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'OmniDriveDAO'

database_id: sqlalchemy.orm.Mapped[int]

x_id: sqlalchemy.orm.Mapped[sqlalchemy.sql.sqltypes.UUID]

y_id: sqlalchemy.orm.Mapped[sqlalchemy.sql.sqltypes.UUID]

roll_id: sqlalchemy.orm.Mapped[sqlalchemy.sql.sqltypes.UUID]

pitch_id: sqlalchemy.orm.Mapped[sqlalchemy.sql.sqltypes.UUID]

yaw_id: sqlalchemy.orm.Mapped[sqlalchemy.sql.sqltypes.UUID]

x_velocity_id: sqlalchemy.orm.Mapped[sqlalchemy.sql.sqltypes.UUID]

y_velocity_id: sqlalchemy.orm.Mapped[sqlalchemy.sql.sqltypes.UUID]

__mapper_args__

class pycram.orm.ormatic_interface.Connection6DoFDAO

Bases: ConnectionDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.connections.Connection6DoF]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'Connection6DoFDAO'

database_id: sqlalchemy.orm.Mapped[int]

x_id: sqlalchemy.orm.Mapped[sqlalchemy.sql.sqltypes.UUID]

y_id: sqlalchemy.orm.Mapped[sqlalchemy.sql.sqltypes.UUID]

z_id: sqlalchemy.orm.Mapped[sqlalchemy.sql.sqltypes.UUID]

qx_id: sqlalchemy.orm.Mapped[sqlalchemy.sql.sqltypes.UUID]

qy_id: sqlalchemy.orm.Mapped[sqlalchemy.sql.sqltypes.UUID]

qz_id: sqlalchemy.orm.Mapped[sqlalchemy.sql.sqltypes.UUID]

qw_id: sqlalchemy.orm.Mapped[sqlalchemy.sql.sqltypes.UUID]

__mapper_args__

class pycram.orm.ormatic_interface.FixedConnectionDAO

Bases: ConnectionDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.connections.FixedConnection]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'FixedConnectionDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.SemanticAnnotationDAO

Bases: WorldEntityDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.world_entity.SemanticAnnotation]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'SemanticAnnotationDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.DoubleDoorDAO

Bases: SemanticAnnotationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.DoubleDoor]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'DoubleDoorDAO'

database_id: sqlalchemy.orm.Mapped[int]

left_door_id: sqlalchemy.orm.Mapped[int]

right_door_id: sqlalchemy.orm.Mapped[int]

left_door: sqlalchemy.orm.Mapped[DoorDAO]

right_door: sqlalchemy.orm.Mapped[DoorDAO]

__mapper_args__

class pycram.orm.ormatic_interface.DrawerDAO

Bases: SemanticAnnotationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Drawer]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'DrawerDAO'

database_id: sqlalchemy.orm.Mapped[int]

container_id: sqlalchemy.orm.Mapped[int]

handle_id: sqlalchemy.orm.Mapped[int]

container: sqlalchemy.orm.Mapped[ContainerDAO]

handle: sqlalchemy.orm.Mapped[HandleDAO]

__mapper_args__

class pycram.orm.ormatic_interface.FridgeDAO

Bases: SemanticAnnotationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Fridge]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'FridgeDAO'

database_id: sqlalchemy.orm.Mapped[int]

container_id: sqlalchemy.orm.Mapped[int]

door_id: sqlalchemy.orm.Mapped[int]

container: sqlalchemy.orm.Mapped[ContainerDAO]

door: sqlalchemy.orm.Mapped[DoorDAO]

__mapper_args__

class pycram.orm.ormatic_interface.FurnitureDAO

Bases: SemanticAnnotationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.mixins.Furniture]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'FurnitureDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.HasBodyDAO

Bases: SemanticAnnotationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.mixins.HasBody]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'HasBodyDAO'

database_id: sqlalchemy.orm.Mapped[int]

body_id: sqlalchemy.orm.Mapped[int]

body: sqlalchemy.orm.Mapped[BodyDAO]

__mapper_args__

class pycram.orm.ormatic_interface.BaseballDAO

Bases: HasBodyDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Baseball]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'BaseballDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.BedDAO

Bases: HasBodyDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Bed]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'BedDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.BookDAO

Bases: HasBodyDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Book]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'BookDAO'

database_id: sqlalchemy.orm.Mapped[int]

book_front_id: sqlalchemy.orm.Mapped[int | None]

book_front: sqlalchemy.orm.Mapped[BookFrontDAO]

__mapper_args__

class pycram.orm.ormatic_interface.BookFrontDAO

Bases: HasBodyDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.BookFront]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'BookFrontDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.ChairDAO

Bases: HasBodyDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Chair]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'ChairDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.ArmchairDAO

Bases: ChairDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Armchair]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'ArmchairDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.OfficeChairDAO

Bases: ChairDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.OfficeChair]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'OfficeChairDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.ClothDAO

Bases: HasBodyDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Cloth]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'ClothDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.ContainerDAO

Bases: HasBodyDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Container]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'ContainerDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.BottleDAO

Bases: ContainerDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Bottle]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'BottleDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.MustardBottleDAO

Bases: BottleDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.MustardBottle]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'MustardBottleDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.SoapBottleDAO

Bases: BottleDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.SoapBottle]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'SoapBottleDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.WineBottleDAO

Bases: BottleDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.WineBottle]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'WineBottleDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.GarbageBinDAO

Bases: ContainerDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.GarbageBin]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'GarbageBinDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.ProcthorBoxDAO

Bases: ContainerDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.ProcthorBox]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'ProcthorBoxDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.SaltContainerDAO

Bases: ContainerDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.SaltContainer]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'SaltContainerDAO'

database_id: sqlalchemy.orm.Mapped[int]

class_label: sqlalchemy.orm.Mapped[str | None]

__mapper_args__

class pycram.orm.ormatic_interface.CookingContainerDAO

Bases: ContainerDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.CookingContainer]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'CookingContainerDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.KettleDAO

Bases: CookingContainerDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Kettle]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'KettleDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.PanDAO

Bases: CookingContainerDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Pan]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'PanDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.PotDAO

Bases: CookingContainerDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Pot]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'PotDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.CuttleryDAO

Bases: HasBodyDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Cuttlery]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'CuttleryDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.ForkDAO

Bases: CuttleryDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Fork]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'ForkDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.KnifeDAO

Bases: CuttleryDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Knife]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'KnifeDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.SpoonDAO

Bases: CuttleryDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Spoon]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'SpoonDAO'

database_id: sqlalchemy.orm.Mapped[int]

class_label: sqlalchemy.orm.Mapped[str | None]

__mapper_args__

class pycram.orm.ormatic_interface.DecorDAO

Bases: HasBodyDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Decor]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'DecorDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.WallDecorDAO

Bases: DecorDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.WallDecor]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'WallDecorDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.PosterDAO

Bases: WallDecorDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Poster]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'PosterDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.DoorDAO

Bases: HasBodyDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Door]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'DoorDAO'

database_id: sqlalchemy.orm.Mapped[int]

handle_id: sqlalchemy.orm.Mapped[int]

handle: sqlalchemy.orm.Mapped[HandleDAO]

__mapper_args__

class pycram.orm.ormatic_interface.DrinkingContainerDAO

Bases: ContainerDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.DrinkingContainer]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'DrinkingContainerDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.CupDAO

Bases: DrinkingContainerDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Cup]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'CupDAO'

database_id: sqlalchemy.orm.Mapped[int]

class_label: sqlalchemy.orm.Mapped[str | None]

__mapper_args__

class pycram.orm.ormatic_interface.MugDAO

Bases: DrinkingContainerDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Mug]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'MugDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.DroneDAO

Bases: HasBodyDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Drone]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'DroneDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.FoodDAO

Bases: HasBodyDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Food]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'FoodDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.BreadDAO

Bases: FoodDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Bread]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'BreadDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.CandyDAO

Bases: FoodDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Candy]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'CandyDAO'

database_id: sqlalchemy.orm.Mapped[int]

class_label: sqlalchemy.orm.Mapped[str | None]

__mapper_args__

class pycram.orm.ormatic_interface.CerealDAO

Bases: FoodDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Cereal]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'CerealDAO'

database_id: sqlalchemy.orm.Mapped[int]

class_label: sqlalchemy.orm.Mapped[str | None]

__mapper_args__

class pycram.orm.ormatic_interface.CheezeItDAO

Bases: FoodDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.CheezeIt]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'CheezeItDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.GelatinBoxDAO

Bases: FoodDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.GelatinBox]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'GelatinBoxDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.MilkDAO

Bases: ContainerDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Milk]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'MilkDAO'

database_id: sqlalchemy.orm.Mapped[int]

class_label: sqlalchemy.orm.Mapped[str | None]

__mapper_args__

class pycram.orm.ormatic_interface.NoodlesDAO

Bases: FoodDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Noodles]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'NoodlesDAO'

database_id: sqlalchemy.orm.Mapped[int]

class_label: sqlalchemy.orm.Mapped[str | None]

__mapper_args__

class pycram.orm.ormatic_interface.PringlesDAO

Bases: FoodDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Pringles]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'PringlesDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.ProduceDAO

Bases: FoodDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Produce]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'ProduceDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.AppleDAO

Bases: ProduceDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Apple]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'AppleDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.BananaDAO

Bases: ProduceDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Banana]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'BananaDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.LettuceDAO

Bases: ProduceDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Lettuce]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'LettuceDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.OrangeDAO

Bases: ProduceDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Orange]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'OrangeDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.PotatoDAO

Bases: ProduceDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Potato]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'PotatoDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.TomatoDAO

Bases: ProduceDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Tomato]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'TomatoDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.TomatoSoupDAO

Bases: FoodDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.TomatoSoup]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'TomatoSoupDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.TunaCanDAO

Bases: FoodDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.TunaCan]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'TunaCanDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.HandleDAO

Bases: HasBodyDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Handle]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'HandleDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.HouseplantDAO

Bases: HasBodyDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Houseplant]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'HouseplantDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.LidDAO

Bases: HasBodyDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Lid]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'LidDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.PanLidDAO

Bases: LidDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.PanLid]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'PanLidDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.PotLidDAO

Bases: LidDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.PotLid]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'PotLidDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.LiquidCapDAO

Bases: HasBodyDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.LiquidCap]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'LiquidCapDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.PenDAO

Bases: HasBodyDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Pen]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'PenDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.PencilDAO

Bases: HasBodyDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Pencil]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'PencilDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.SaltPepperShakerDAO

Bases: HasBodyDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.SaltPepperShaker]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'SaltPepperShakerDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.ShelvingUnitDAO

Bases: HasBodyDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.ShelvingUnit]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'ShelvingUnitDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.SinkDAO

Bases: HasBodyDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Sink]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'SinkDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.SofaDAO

Bases: HasBodyDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Sofa]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'SofaDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.SprayBottleDAO

Bases: HasBodyDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.SprayBottle]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'SprayBottleDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.StatueDAO

Bases: HasBodyDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Statue]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'StatueDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.TableDAO

Bases: FurnitureDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Table]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'TableDAO'

database_id: sqlalchemy.orm.Mapped[int]

body_id: sqlalchemy.orm.Mapped[int]

body: sqlalchemy.orm.Mapped[BodyDAO]

__mapper_args__

class pycram.orm.ormatic_interface.CoffeeTableDAO

Bases: TableDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.CoffeeTable]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'CoffeeTableDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.DeskDAO

Bases: TableDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Desk]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'DeskDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.DiningTableDAO

Bases: TableDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.DiningTable]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'DiningTableDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.SideTableDAO

Bases: TableDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.SideTable]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'SideTableDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.VaseDAO

Bases: HasBodyDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Vase]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'VaseDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.WallPanelDAO

Bases: HasBodyDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.WallPanel]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'WallPanelDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.HasDoorsDAO

Bases: SemanticAnnotationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.mixins.HasDoors]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'HasDoorsDAO'

database_id: sqlalchemy.orm.Mapped[int]

doors: sqlalchemy.orm.Mapped[List[DoorDAO]]

__mapper_args__

class pycram.orm.ormatic_interface.CupboardDAO

Bases: FurnitureDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Cupboard]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'CupboardDAO'

database_id: sqlalchemy.orm.Mapped[int]

container_id: sqlalchemy.orm.Mapped[int]

doors: sqlalchemy.orm.Mapped[List[DoorDAO]]

container: sqlalchemy.orm.Mapped[ContainerDAO]

__mapper_args__

class pycram.orm.ormatic_interface.HasDrawersDAO

Bases: SemanticAnnotationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.mixins.HasDrawers]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'HasDrawersDAO'

database_id: sqlalchemy.orm.Mapped[int]

drawers: sqlalchemy.orm.Mapped[List[DrawerDAO]]

__mapper_args__

class pycram.orm.ormatic_interface.CabinetDAO

Bases: FurnitureDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Cabinet]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'CabinetDAO'

database_id: sqlalchemy.orm.Mapped[int]

container_id: sqlalchemy.orm.Mapped[int]

doors: sqlalchemy.orm.Mapped[List[DoorDAO]]

drawers: sqlalchemy.orm.Mapped[List[DrawerDAO]]

container: sqlalchemy.orm.Mapped[ContainerDAO]

__mapper_args__

class pycram.orm.ormatic_interface.DresserDAO

Bases: FurnitureDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Dresser]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'DresserDAO'

database_id: sqlalchemy.orm.Mapped[int]

container_id: sqlalchemy.orm.Mapped[int]

doors: sqlalchemy.orm.Mapped[List[DoorDAO]]

drawers: sqlalchemy.orm.Mapped[List[DrawerDAO]]

container: sqlalchemy.orm.Mapped[ContainerDAO]

__mapper_args__

class pycram.orm.ormatic_interface.WardrobeDAO

Bases: FurnitureDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Wardrobe]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'WardrobeDAO'

database_id: sqlalchemy.orm.Mapped[int]

container_id: sqlalchemy.orm.Mapped[int]

doors: sqlalchemy.orm.Mapped[List[DoorDAO]]

drawers: sqlalchemy.orm.Mapped[List[DrawerDAO]]

container: sqlalchemy.orm.Mapped[ContainerDAO]

__mapper_args__

class pycram.orm.ormatic_interface.HasRegionDAO

Bases: SemanticAnnotationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.mixins.HasRegion]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'HasRegionDAO'

database_id: sqlalchemy.orm.Mapped[int]

region_id: sqlalchemy.orm.Mapped[int]

region: sqlalchemy.orm.Mapped[RegionDAO]

__mapper_args__

class pycram.orm.ormatic_interface.ApertureDAO

Bases: HasRegionDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Aperture]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'ApertureDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.HasSupportingSurfaceDAO

Bases: SemanticAnnotationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.mixins.HasSupportingSurface]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'HasSupportingSurfaceDAO'

database_id: sqlalchemy.orm.Mapped[int]

supporting_surface_id: sqlalchemy.orm.Mapped[int | None]

supporting_surface: sqlalchemy.orm.Mapped[RegionDAO]

__mapper_args__

class pycram.orm.ormatic_interface.BowlDAO

Bases: HasBodyDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Bowl]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'BowlDAO'

database_id: sqlalchemy.orm.Mapped[int]

class_label: sqlalchemy.orm.Mapped[str | None]

supporting_surface_id: sqlalchemy.orm.Mapped[int | None]

supporting_surface: sqlalchemy.orm.Mapped[RegionDAO]

__mapper_args__

class pycram.orm.ormatic_interface.FloorDAO

Bases: HasSupportingSurfaceDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Floor]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'FloorDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.PlateDAO

Bases: HasBodyDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Plate]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'PlateDAO'

database_id: sqlalchemy.orm.Mapped[int]

supporting_surface_id: sqlalchemy.orm.Mapped[int | None]

supporting_surface: sqlalchemy.orm.Mapped[RegionDAO]

__mapper_args__

class pycram.orm.ormatic_interface.RoomDAO

Bases: SemanticAnnotationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Room]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'RoomDAO'

database_id: sqlalchemy.orm.Mapped[int]

floor_id: sqlalchemy.orm.Mapped[int]

floor: sqlalchemy.orm.Mapped[FloorDAO]

__mapper_args__

class pycram.orm.ormatic_interface.RootedSemanticAnnotationDAO

Bases: SemanticAnnotationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.world_entity.RootedSemanticAnnotation]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'RootedSemanticAnnotationDAO'

database_id: sqlalchemy.orm.Mapped[int]

root_id: sqlalchemy.orm.Mapped[int]

root: sqlalchemy.orm.Mapped[BodyDAO]

__mapper_args__

class pycram.orm.ormatic_interface.AgentDAO

Bases: RootedSemanticAnnotationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.world_entity.Agent]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'AgentDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.AbstractRobotDAO

Bases: AgentDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.robots.abstract_robot.AbstractRobot]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'AbstractRobotDAO'

database_id: sqlalchemy.orm.Mapped[int]

torso_id: sqlalchemy.orm.Mapped[int | None]

default_collision_config_id: sqlalchemy.orm.Mapped[int]

torso: sqlalchemy.orm.Mapped[TorsoDAO]

manipulators: sqlalchemy.orm.Mapped[List[ManipulatorDAO]]

sensors: sqlalchemy.orm.Mapped[List[SensorDAO]]

manipulator_chains: sqlalchemy.orm.Mapped[List[KinematicChainDAO]]

sensor_chains: sqlalchemy.orm.Mapped[List[KinematicChainDAO]]

default_collision_config: sqlalchemy.orm.Mapped[CollisionCheckingConfigDAO]

__mapper_args__

class pycram.orm.ormatic_interface.HumanDAO

Bases: AgentDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.world_entity.Human]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'HumanDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.SemanticEnvironmentAnnotationDAO

Bases: RootedSemanticAnnotationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.world_entity.SemanticEnvironmentAnnotation]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'SemanticEnvironmentAnnotationDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.SemanticRobotAnnotationDAO

Bases: RootedSemanticAnnotationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.robots.abstract_robot.SemanticRobotAnnotation]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'SemanticRobotAnnotationDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.KinematicChainDAO

Bases: SemanticRobotAnnotationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.robots.abstract_robot.KinematicChain]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'KinematicChainDAO'

database_id: sqlalchemy.orm.Mapped[int]

tip_id: sqlalchemy.orm.Mapped[int]

manipulator_id: sqlalchemy.orm.Mapped[int | None]

tip: sqlalchemy.orm.Mapped[BodyDAO]

manipulator: sqlalchemy.orm.Mapped[ManipulatorDAO]

sensors: sqlalchemy.orm.Mapped[List[SensorDAO]]

__mapper_args__

class pycram.orm.ormatic_interface.ArmDAO

Bases: KinematicChainDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.robots.abstract_robot.Arm]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'ArmDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.FingerDAO

Bases: KinematicChainDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.robots.abstract_robot.Finger]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'FingerDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.NeckDAO

Bases: KinematicChainDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.robots.abstract_robot.Neck]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'NeckDAO'

database_id: sqlalchemy.orm.Mapped[int]

pitch_body_id: sqlalchemy.orm.Mapped[int | None]

yaw_body_id: sqlalchemy.orm.Mapped[int | None]

pitch_body: sqlalchemy.orm.Mapped[BodyDAO]

yaw_body: sqlalchemy.orm.Mapped[BodyDAO]

__mapper_args__

class pycram.orm.ormatic_interface.TorsoDAO

Bases: KinematicChainDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.robots.abstract_robot.Torso]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'TorsoDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.ManipulatorDAO

Bases: SemanticRobotAnnotationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.robots.abstract_robot.Manipulator]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'ManipulatorDAO'

database_id: sqlalchemy.orm.Mapped[int]

tool_frame_id: sqlalchemy.orm.Mapped[int]

front_facing_orientation_id: sqlalchemy.orm.Mapped[int]

front_facing_axis_id: sqlalchemy.orm.Mapped[int]

tool_frame: sqlalchemy.orm.Mapped[BodyDAO]

front_facing_orientation: sqlalchemy.orm.Mapped[QuaternionMappingDAO]

front_facing_axis: sqlalchemy.orm.Mapped[Vector3MappingDAO]

__mapper_args__

class pycram.orm.ormatic_interface.ParallelGripperDAO

Bases: ManipulatorDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.robots.abstract_robot.ParallelGripper]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'ParallelGripperDAO'

database_id: sqlalchemy.orm.Mapped[int]

finger_id: sqlalchemy.orm.Mapped[int]

thumb_id: sqlalchemy.orm.Mapped[int]

finger: sqlalchemy.orm.Mapped[FingerDAO]

thumb: sqlalchemy.orm.Mapped[FingerDAO]

__mapper_args__

class pycram.orm.ormatic_interface.SensorDAO

Bases: SemanticRobotAnnotationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.robots.abstract_robot.Sensor]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'SensorDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.CameraDAO

Bases: SensorDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.robots.abstract_robot.Camera]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'CameraDAO'

database_id: sqlalchemy.orm.Mapped[int]

minimal_height: sqlalchemy.orm.Mapped[float]

maximal_height: sqlalchemy.orm.Mapped[float]

forward_facing_axis_id: sqlalchemy.orm.Mapped[int]

field_of_view_id: sqlalchemy.orm.Mapped[int]

forward_facing_axis: sqlalchemy.orm.Mapped[Vector3MappingDAO]

field_of_view: sqlalchemy.orm.Mapped[FieldOfViewDAO]

__mapper_args__

class pycram.orm.ormatic_interface.WallDAO

Bases: SemanticAnnotationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.semantic_annotations.semantic_annotations.Wall]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'WallDAO'

database_id: sqlalchemy.orm.Mapped[int]

body_id: sqlalchemy.orm.Mapped[int]

body: sqlalchemy.orm.Mapped[BodyDAO]

__mapper_args__

class pycram.orm.ormatic_interface.WorldEntityWithIDDAO

Bases: WorldEntityDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.world_entity.WorldEntityWithID]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'WorldEntityWithIDDAO'

database_id: sqlalchemy.orm.Mapped[int]

id: sqlalchemy.orm.Mapped[sqlalchemy.sql.sqltypes.UUID]

__mapper_args__

class pycram.orm.ormatic_interface.ActuatorDAO

Bases: WorldEntityWithIDDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.world_entity.Actuator]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'ActuatorDAO'

database_id: sqlalchemy.orm.Mapped[int]

__mapper_args__

class pycram.orm.ormatic_interface.DegreeOfFreedomMappingDAO

Bases: WorldEntityWithIDDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.orm.model.DegreeOfFreedomMapping]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'DegreeOfFreedomMappingDAO'

database_id: sqlalchemy.orm.Mapped[int]

lower_limits: sqlalchemy.orm.Mapped[List[float]]

upper_limits: sqlalchemy.orm.Mapped[List[float]]

__mapper_args__

class pycram.orm.ormatic_interface.KinematicStructureEntityDAO

Bases: WorldEntityWithIDDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.world_entity.KinematicStructureEntity]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'KinematicStructureEntityDAO'

database_id: sqlalchemy.orm.Mapped[int]

index: sqlalchemy.orm.Mapped[int | None]

__mapper_args__

class pycram.orm.ormatic_interface.BodyDAO

Bases: KinematicStructureEntityDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.world_entity.Body]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'BodyDAO'

database_id: sqlalchemy.orm.Mapped[int]

visual_id: sqlalchemy.orm.Mapped[int]

collision_id: sqlalchemy.orm.Mapped[int]

collision_config_id: sqlalchemy.orm.Mapped[int | None]

temp_collision_config_id: sqlalchemy.orm.Mapped[int | None]

visual: sqlalchemy.orm.Mapped[ShapeCollectionDAO]

collision: sqlalchemy.orm.Mapped[ShapeCollectionDAO]

collision_config: sqlalchemy.orm.Mapped[CollisionCheckingConfigDAO]

temp_collision_config: sqlalchemy.orm.Mapped[CollisionCheckingConfigDAO]

__mapper_args__

class pycram.orm.ormatic_interface.RegionDAO

Bases: KinematicStructureEntityDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.world_entity.Region]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'RegionDAO'

database_id: sqlalchemy.orm.Mapped[int]

area_id: sqlalchemy.orm.Mapped[int]

area: sqlalchemy.orm.Mapped[ShapeCollectionDAO]

__mapper_args__

class pycram.orm.ormatic_interface.WorldModelModificationDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.world_modification.WorldModelModification]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'WorldModelModificationDAO'

database_id: sqlalchemy.orm.Mapped[int]

polymorphic_type: sqlalchemy.orm.Mapped[str]

__mapper_args__

class pycram.orm.ormatic_interface.AddActuatorModificationDAO

Bases: WorldModelModificationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.world_modification.AddActuatorModification]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'AddActuatorModificationDAO'

database_id: sqlalchemy.orm.Mapped[int]

actuator_id: sqlalchemy.orm.Mapped[int]

actuator: sqlalchemy.orm.Mapped[ActuatorDAO]

__mapper_args__

class pycram.orm.ormatic_interface.AddConnectionModificationDAO

Bases: WorldModelModificationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.world_modification.AddConnectionModification]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'AddConnectionModificationDAO'

database_id: sqlalchemy.orm.Mapped[int]

connection_id: sqlalchemy.orm.Mapped[int]

connection: sqlalchemy.orm.Mapped[ConnectionDAO]

__mapper_args__

class pycram.orm.ormatic_interface.AddDegreeOfFreedomModificationDAO

Bases: WorldModelModificationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.world_modification.AddDegreeOfFreedomModification]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'AddDegreeOfFreedomModificationDAO'

database_id: sqlalchemy.orm.Mapped[int]

dof_id: sqlalchemy.orm.Mapped[int]

dof: sqlalchemy.orm.Mapped[DegreeOfFreedomMappingDAO]

__mapper_args__

class pycram.orm.ormatic_interface.AddKinematicStructureEntityModificationDAO

Bases: WorldModelModificationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.world_modification.AddKinematicStructureEntityModification]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'AddKinematicStructureEntityModificationDAO'

database_id: sqlalchemy.orm.Mapped[int]

kinematic_structure_entity_id: sqlalchemy.orm.Mapped[int]

kinematic_structure_entity: sqlalchemy.orm.Mapped[KinematicStructureEntityDAO]

__mapper_args__

class pycram.orm.ormatic_interface.AddSemanticAnnotationModificationDAO

Bases: WorldModelModificationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.world_modification.AddSemanticAnnotationModification]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'AddSemanticAnnotationModificationDAO'

database_id: sqlalchemy.orm.Mapped[int]

semantic_annotation_id: sqlalchemy.orm.Mapped[int]

semantic_annotation: sqlalchemy.orm.Mapped[SemanticAnnotationDAO]

__mapper_args__

class pycram.orm.ormatic_interface.RemoveActuatorModificationDAO

Bases: WorldModelModificationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.world_modification.RemoveActuatorModification]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'RemoveActuatorModificationDAO'

database_id: sqlalchemy.orm.Mapped[int]

actuator_id: sqlalchemy.orm.Mapped[sqlalchemy.sql.sqltypes.UUID]

__mapper_args__

class pycram.orm.ormatic_interface.RemoveBodyModificationDAO

Bases: WorldModelModificationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.world_modification.RemoveBodyModification]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'RemoveBodyModificationDAO'

database_id: sqlalchemy.orm.Mapped[int]

body_id: sqlalchemy.orm.Mapped[sqlalchemy.sql.sqltypes.UUID]

__mapper_args__

class pycram.orm.ormatic_interface.RemoveConnectionModificationDAO

Bases: WorldModelModificationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.world_modification.RemoveConnectionModification]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'RemoveConnectionModificationDAO'

database_id: sqlalchemy.orm.Mapped[int]

parent_id: sqlalchemy.orm.Mapped[sqlalchemy.sql.sqltypes.UUID]

child_id: sqlalchemy.orm.Mapped[sqlalchemy.sql.sqltypes.UUID]

__mapper_args__

class pycram.orm.ormatic_interface.RemoveDegreeOfFreedomModificationDAO

Bases: WorldModelModificationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.world_modification.RemoveDegreeOfFreedomModification]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'RemoveDegreeOfFreedomModificationDAO'

database_id: sqlalchemy.orm.Mapped[int]

dof_id: sqlalchemy.orm.Mapped[sqlalchemy.sql.sqltypes.UUID]

__mapper_args__

class pycram.orm.ormatic_interface.RemoveSemanticAnnotationModificationDAO

Bases: WorldModelModificationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.world_modification.RemoveSemanticAnnotationModification]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'RemoveSemanticAnnotationModificationDAO'

database_id: sqlalchemy.orm.Mapped[int]

semantic_annotation_id: sqlalchemy.orm.Mapped[int]

semantic_annotation: sqlalchemy.orm.Mapped[SemanticAnnotationDAO]

__mapper_args__

class pycram.orm.ormatic_interface.SetDofHasHardwareInterfaceDAO

Bases: WorldModelModificationDAO, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.world_modification.SetDofHasHardwareInterface]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'SetDofHasHardwareInterfaceDAO'

database_id: sqlalchemy.orm.Mapped[int]

value: sqlalchemy.orm.Mapped[bool]

degree_of_freedom_ids: sqlalchemy.orm.Mapped[List[uuid.UUID]]

__mapper_args__

class pycram.orm.ormatic_interface.WorldModelModificationBlockDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.world_description.world_modification.WorldModelModificationBlock]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'WorldModelModificationBlockDAO'

database_id: sqlalchemy.orm.Mapped[int]

modifications: sqlalchemy.orm.Mapped[List[WorldModelModificationDAO]]

class pycram.orm.ormatic_interface.WorldStateMappingDAO

Bases: Base, krrood.ormatic.dao.DataAccessObject[semantic_digital_twin.orm.model.WorldStateMapping]

Base class used for declarative class definitions.

The _orm.DeclarativeBase allows for the creation of new declarative bases in such a way that is compatible with type checkers:

from sqlalchemy.orm import DeclarativeBase


class Base(DeclarativeBase):
    pass

The above Base class is now usable as the base for new declarative mappings. The superclass makes use of the __init_subclass__() method to set up new classes and metaclasses aren’t used.

When first used, the _orm.DeclarativeBase class instantiates a new _orm.registry to be used with the base, assuming one was not provided explicitly. The _orm.DeclarativeBase class supports class-level attributes which act as parameters for the construction of this registry; such as to indicate a specific _schema.MetaData collection as well as a specific value for :paramref:`_orm.registry.type_annotation_map`:

from typing_extensions import Annotated

from sqlalchemy import BigInteger
from sqlalchemy import MetaData
from sqlalchemy import String
from sqlalchemy.orm import DeclarativeBase

bigint = Annotated[int, "bigint"]
my_metadata = MetaData()


class Base(DeclarativeBase):
    metadata = my_metadata
    type_annotation_map = {
        str: String().with_variant(String(255), "mysql", "mariadb"),
        bigint: BigInteger(),
    }

Class-level attributes which may be specified include:

Parameters:

• metadata – optional _schema.MetaData collection. If a _orm.registry is constructed automatically, this _schema.MetaData collection will be used to construct it. Otherwise, the local _schema.MetaData collection will supercede that used by an existing _orm.registry passed using the :paramref:`_orm.DeclarativeBase.registry` parameter.

• type_annotation_map – optional type annotation map that will be passed to the _orm.registry as :paramref:`_orm.registry.type_annotation_map`.

• registry – supply a pre-existing _orm.registry directly.

Added in version 2.0: Added DeclarativeBase, so that declarative base classes may be constructed in such a way that is also recognized by PEP 484 type checkers. As a result, DeclarativeBase and other subclassing-oriented APIs should be seen as superseding previous “class returned by a function” APIs, namely _orm.declarative_base() and _orm.registry.generate_base(), where the base class returned cannot be recognized by type checkers without using plugins.

__init__ behavior

In a plain Python class, the base-most __init__() method in the class hierarchy is object.__init__(), which accepts no arguments. However, when the _orm.DeclarativeBase subclass is first declared, the class is given an __init__() method that links to the :paramref:`_orm.registry.constructor` constructor function, if no __init__() method is already present; this is the usual declarative constructor that will assign keyword arguments as attributes on the instance, assuming those attributes are established at the class level (i.e. are mapped, or are linked to a descriptor). This constructor is never accessed by a mapped class without being called explicitly via super(), as mapped classes are themselves given an __init__() method directly which calls :paramref:`_orm.registry.constructor`, so in the default case works independently of what the base-most __init__() method does.

Changed in version 2.0.1: _orm.DeclarativeBase has a default constructor that links to :paramref:`_orm.registry.constructor` by default, so that calls to super().__init__() can access this constructor. Previously, due to an implementation mistake, this default constructor was missing, and calling super().__init__() would invoke object.__init__().

The _orm.DeclarativeBase subclass may also declare an explicit __init__() method which will replace the use of the :paramref:`_orm.registry.constructor` function at this level:

class Base(DeclarativeBase):
    def __init__(self, id=None):
        self.id = id

Mapped classes still will not invoke this constructor implicitly; it remains only accessible by calling super().__init__():

class MyClass(Base):
    def __init__(self, id=None, name=None):
        self.name = name
        super().__init__(id=id)

Note that this is a different behavior from what functions like the legacy _orm.declarative_base() would do; the base created by those functions would always install :paramref:`_orm.registry.constructor` for __init__().

__tablename__ = 'WorldStateMappingDAO'

database_id: sqlalchemy.orm.Mapped[int]

data: sqlalchemy.orm.Mapped[List[float]]

ids: sqlalchemy.orm.Mapped[List[uuid.UUID]]